To: OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
>Like everyone knows, both ODF and OpenDoc use a 16.16 fixed-point
>coordinate system. Without changing the coordinate mapping, the maximum
>number of pages in the vertical direction is about 40 pages. While this is
>enough for a leaf part or ODF Draw, many container (root) parts display
>content that can easily exceed this limit. Text processors and
>spreadsheets are examples of parts that exceed this limit.
>
>Both OpenDoc and ODF claim that you can change this size by scaling your
>coordinates. Henri has suggested that we just view the fixed-point numbers
>as 24.8 fixed-point numbers. Kurt Piersol (in Develop 21) suggests using
>fixed-point inches instead of points. We've been spending the past couple
>of days looking into supporting a larger view space. It turns out that
>it's not that simple.
>
>Simply changing the scaling is only part of the problem. The other part of
>the problem is how to handle the 32-bit coordinate space, since QuickDraw
>is limited to 16 bits. We need 32-bit coordinates, then a way to map them
>back & forth from 16-bit space when we render, handle mouse clicks, etc.
>
>We've looked at MacApp and PowerPlant; they both use port tiling at 1K
>(MacApp) and 16K (PowerPlant) to achieve canvasses of arbitrary size.
>
>We've tried subclassing FW_CView, keeping our own member variable that's in
>32-bit space, but it looks like we'll have problems, since all of the
>coordinate conversion methods, like FrameToView and ViewToFrame, are not
>declared virtual.
>
>What we're trying to do is something that a lot of developers will have to
>deal with. This problem should be solved once in ODF, like MacApp has
>done. Until ODF solves this problem, it can't be used for serious
>spreadsheets or text processing.
>
>In the meantime, can you give us a recipe that provides a solution using
>ODF R1?
>
>Regards,
> The Digital Harbor Development Team
>
>
There were a couple of messages on the list about this problem. I also talked with you (or someone from your team) at WWDC. This is not an easy fix and there is no quick recipe I can give you. ODF release 1 (and ODF release 2) are limited to 16 bits view extent. We hope to have that fixed by ODF Release 3. The way to solve that right now is to do the same thing you would be doing if your were not using a framework. How people were able to scroll thousand of pages using the Mac Toolbox only? You cannot call SetOrigin with a 32 bits offset.
I think a way to solve this problem is to keep the size of your document in a 32 bits extent and have an offset telling you where the top of the view extent is in your document (would be nice to be able to draw something here). The view extent should be set to the maximum value possible. When your are at the top of your document both the offset and the frame internal transforn are zero. When the user starts scrolling you can use the normal scrolling until you reach the 16 bits limit. At this point you should set your offset to ≈32000 and reset the internal transform to ≈zero and continue scrolling. You would have to change your rendering to take into account this offset. You will also have to be able to describe embedded frames position in 32 bits coordinates and take into account the offset when recalculating the facet external transform. You may also have to do some work to have the scrollbar thumb be positionned correctly.
I understand this is a very rough description but it should work. What do you think?
